在前一篇我們提到binlog可以當作資料恢復的重要紀錄，今天要介紹的是binlog另一個主要功能用於MYSQL主從複製(Master-Slave Replication)。

What is 主從複製？

Ans: 藉由主從複製將數據從主庫(Master)複製到1至多台從服務器(Slave)，達到主從數據一致，增加數據可用性。

因為資料是一致的所以相當於多一個備用系統能在發生單點故障問題時或實務應用查詢資料上使用。

實務應用

• 生產環境下的效能:

採數據讀寫分離，所有寫入更新異動操作皆由主庫(Master)執行，而讀取相關的撈資料語法轉至從庫(Slave)執行。

解決目的:
不但能分散單點在大量負載請求下的壓力，也能避免部分長時間語法造成表鎖導致無法正常使用服務的問題。

• 擴展性&系統異常處理:

在一主多從的架構下可以增加服務數據可用性，且當主從服務器有任一台發生異常時，可以透過切換節點，直接取代掉有問題的那台上線運作。

針對以上圖例子來說，看例子好理解～ ps.遇到緊急無法及時處理的狀況

1. master 主服務有問題 --處理--> 將其中一台slave轉master

   (可能要注意一些只在master上的參數記得做切換)

2. slave 從服務有問題 --處理--> 將備援slave轉正式slave，保持系統可用性。

• 資料備份：

在從庫上實施日常例行備份，同時也能避免在備份時可能造成的效能影響及空間上佔用，減少影響主庫的因素！

流程圖

搭建主從架構前先從以下圖了解主從複製在流程上是如何運作!!

首先對於每個 Master-Slave 連接來說都會啟用3個線程來完成主從複製的動作。

• Master -> (binlog dump thread) 日誌: binlog
• Slave -> (I/O thread & SQL thread) 日誌: relay log(中繼日誌)

1. master- 產生binlog紀錄

   • 在master開啟binlog下，當client端寫入更新資料，在該次事務完成之前，會以事件形式將該次異動寫入binlog日誌。

2. slave- I/O thread作用

   • 當slave建立用戶端啟動I/O thread連接master後，master會為當前連接建一個binlog dump thread 用來讀取發送binlog內容。

   • I/O thread 通過請求主庫的binlog dump thread讀取指定binlog文件內的指定位置之後的事件，將內容(除了日誌訊息還會包含本次返回的binlog文件&位置紀錄)回給slave的I/O thread。

   • 當I/O thread 獲取到binlog的更新內容後，會將其寫入中繼日誌，另外會將該次讀取到的binlog文件位置記錄到master.info文件中。 (ps. relay log 和 master.info文件皆位於slave的mysql目錄下。)

3. Slave- SQL thread作用

   • slave的 SQL thread 會檢測中繼日誌讀取新增的事件內容，解析事件內容執行重放更新slave的資料，使slave與master中的數據一致。

Q: 為何還要分I/O & SQL thread 存取relay log 而不選擇一條龍流程做好更新？

Ans: 將2個線程分成獨立工作，I/O(獲取更新內容)＆SQL(執行更新內容)。

這樣就能避免掉互相等待的狀況，像是slave執行更新完成才能送下一個新的事件內容。

今天我們了解主從機制流程上的運行後，明天來實際搭建一個主從架構～